Hier verwenden wir arp-scan -l
, um alle aktiven Hosts im lokalen Netzwerk zu finden. Das Ergebnis zeigt, dass sich ein Gerät mit der IP-Adresse 192.168.2.142 im Netzwerk befindet.
Die MAC-Adresse und der Hersteller (PCS Systemtechnik GmbH) werden ebenfalls angezeigt, was uns erste Hinweise auf das Gerät gibt.
Mit nmap
führen wir einen umfassenden Scan des Zielsystems (192.168.2.142) durch. Wir verwenden die Optionen -sS
(SYN-Scan), -sC
(Standard-Skripte), -Pn
(kein Ping), -A
(aggressive Erkennung) und -p-
(alle Ports).
Das Ergebnis zeigt, dass die Ports 22 (SSH) und 80 (HTTP) offen sind. Dies deutet darauf hin, dass auf dem System ein SSH-Server und ein Webserver laufen. Die Versionen der Dienste (penSSH 5.9p1 und Apache httpd 2.2.22) werden ebenfalls angezeigt.
Dieser nmap
-Scan ist detaillierter. Die Option -T5
beschleunigt den Scan, und die Ausgabe zeigt zusätzliche Informationen wie SSH-Hostkeys, HTTP-Cookie-Flags und den HTTP-Titel der Webseite ("--[[IndiShell Lab]]--").
Wir erfahren auch, dass es sich um ein Ubuntu-System handelt und die MAC-Adresse auf eine virtuelle Maschine von racle VirtualBox hinweist. Dies hilft uns, die Umgebung besser zu verstehen.
In der Web Enumeration-Phase konzentrieren wir uns auf die Analyse der Webanwendung, um Schwachstellen und interessante Endpunkte zu finden. Wir verwenden Tools wie nikto
und gobuster
, um das System auf Sicherheitslücken und versteckte Verzeichnisse zu überprüfen.
nikto
ist ein Webserver-Scanner, der auf bekannte Schwachstellen und Konfigurationsfehler prüft. Die Ausgabe zeigt eine Vielzahl von potenziellen Problemen, wie z.B. fehlende HTTPonly-Flags für Cookies, aktivierte MultiViews, Directory Indexing und die Offenlegung interner IP-Adressen.
Besonders interessant ist der Hinweis auf /test.php
, der weiter untersucht werden sollte.
Hier versuchen wir, die Datei /etc/passwd
über den Parameter file
in test.php
auszulesen. Die Fehlermeldung deutet darauf hin, dass der Parameter zwar vorhanden ist, aber leer ist.
Dies könnte auf eine Local File Inclusion (LFI)-Schwachstelle hindeuten, die wir später genauer untersuchen werden.
Mit der Option -Iv
fordern wir nur die Header der Antwort an. Der Statuscode 200 OK
zeigt, dass die Anfrage erfolgreich war. Interessant ist der X-Powered-By
-Header, der die PHP-Version (5.3.10) offenlegt.
Diese Information kann nützlich sein, um spezifische Schwachstellen in dieser PHP-Version zu finden.
gobuster
wird verwendet, um versteckte Verzeichnisse und Dateien auf dem Webserver zu finden. Die Ausgabe zeigt eine Liste von gefundenen Pfaden, darunter /index
, /images
, /in.php
, /test.php
und /panel
.
Besonders interessant sind /in.php
(phpinfo()), /test.php
(das wir bereits untersucht haben) und /panel
, das auf eine Admin-Oberfläche hindeuten könnte.
Hier senden wir eine PST-Anfrage (vermutlich ein Tippfehler und sollte POST sein) mit dem Parameter file
auf /etc/passwd
an test.php
. Im Gegensatz zum vorherigen Versuch erhalten wir jetzt den Inhalt der Datei.
Dies bestätigt die LFI-Schwachstelle. Wir sehen, dass der Benutzer ica
existiert, was uns bei späteren Angriffen helfen könnte.
Nachdem wir eine LFI-Schwachstelle entdeckt haben, versuchen wir, uns Zugriff auf das System zu verschaffen. Wir nutzen die Schwachstelle, um sensitive Daten auszulesen und potenzielle Anmeldeinformationen zu finden.
Hier versuchen wir, das Passwort des Benutzers ica
per Brute-Force über SSH zu knacken. Wir verwenden hydra
mit der Wordlist rockyou.txt
. Die Warnmeldungen deuten darauf hin, dass die Anzahl der parallelen Tasks reduziert werden sollte.
Dieser Schritt kann zeitaufwendig sein, aber er ist ein direkter Versuch, uns Zugriff auf das System zu verschaffen.
Wir versuchen, den privaten SSH-Schlüssel des Benutzers ica
über die LFI-Schwachstelle auszulesen. Die Meldung "file not found" deutet darauf hin, dass die Datei nicht vorhanden ist oder wir keine Berechtigung haben, sie zu lesen.
Auch wenn dieser Versuch fehlschlägt, ist es wichtig, solche Möglichkeiten zu prüfen.
Wir lesen den Quellcode von index.php
, um die Login-Funktionalität zu verstehen. Der Code deutet auf eine SQL Injection-Schwachstelle hin, da die Eingaben nicht ausreichend bereinigt werden.
Dies ist ein vielversprechender Ansatzpunkt für weitere Angriffe.
Wir lesen den Quellcode von c.php
, um die Datenbankverbindungsinformationen zu erhalten. Wir finden den Benutzernamen billu
, das Passwort b0x_billu
und den Datenbanknamen ica_lab
.
Diese Anmeldeinformationen sind äußerst wertvoll und könnten uns direkten Zugriff auf die Datenbank ermöglichen.
Wiederholung des Quellcodes von index.php
, um die SQL Injection-Schwachstelle zu verdeutlichen. Die Eingaben $uname
und $pass
werden nur unzureichend bereinigt.
Wir nutzen die SQL Injection-Schwachstelle, um uns als Administrator anzumelden. Die Nutzdaten un=admin' R 1=1 -- &ps=password
umgehen die Authentifizierung.
Die Antwort "You are allowed" bestätigt, dass wir uns erfolgreich angemeldet haben.
Nachdem wir uns als Administrator angemeldet haben, versuchen wir, unsere Privilegien zu erhöhen, um Root-Zugriff zu erhalten.
Wir lesen die Konfigurationsdatei von phpMyAdmin, um Datenbankanmeldeinformationen zu finden. Wir entdecken das Root-Passwort roottoor
.
Dieses Passwort könnte uns Root-Zugriff auf das System ermöglichen.
Dieser Proof of Concept demonstriert, wie wir den Root-Zugriff auf das System erlangen, indem wir das in der phpMyAdmin-Konfigurationsdatei gefundene Passwort verwenden.
Wir versuchen, uns über SSH als Root anzumelden und verwenden das Passwort roottoor
. Die erfolgreiche Anmeldung zeigt, dass das Passwort korrekt ist.
Fantastisch! Der Root-Zugriff war erfolgreich, nun haben wir unser Ziel erreicht.
Wir führen den Befehl ls -la
aus, um den Inhalt des Root-Verzeichnisses anzuzeigen. Dies bestätigt, dass wir uns im Root-Verzeichnis befinden und Root-Rechte haben.
Der Befehl pwd
(print working directory) bestätigt, dass wir uns im Verzeichnis /root
befinden.
Wir suchen nach der Datei root.txt
im gesamten Dateisystem. Die Ausgabe ist leer, was bedeutet, dass die Datei nicht gefunden wurde.
Hier wird der Hex-Header einer PNG-Datei in die Datei shell.png
geschrieben. Dies könnte dazu dienen, eine Datei als PNG-Datei zu tarnen oder zu manipulieren.
Dieser Schritt ist unklar im Kontext der Privilege Escalation, könnte aber Teil eines weiterführenden Angriffs sein.
In der Reconnaissance-Phase sammeln wir Informationen über das Zielsystem. Wir beginnen mit der Identifizierung von Hosts im Netzwerk und der Analyse offener Ports und Dienste, um potenzielle Angriffsflächen zu identifizieren.
Dieser Schritt ist entscheidend, um ein umfassendes Bild der Systemarchitektur und der laufenden Anwendungen zu erhalten, was die Grundlage für spätere Schritte bildet.